A graphics path generally represents a graphic, drawing or image in a graphics description language, such as SVG (standing for “Scalable Vector Graphics”), DrawML or Microsoft Silverlight (trademark). For the purposes of explanation, the following description focuses on the SVG standard.
In a known manner, the SVG standard is an XML grammar for stylable graphics, usable as an XML namespace, to describe vector graphics drawings.
Thanks to the vector-based approach, an SVG image can be rendered at any given resolution without loss of precision.
SVG uses the XML syntax to define a set of elements and attributes describing geometric shapes, transformations, colours or animations. For example, an XML element may define a draw command and comprise coordinate or parameter attributes associated with the command.
Simple geometric shapes allowed by SVG are rectangles, circles, ellipses, lines and even polygons.
More complex shapes may be drawn using a specific tool, namely the SVG path, and corresponding XML element <path d=“ . . . ”>.
The SVG path represents the outline of a shape and is written as a sequence of draw commands and associated arguments, such as coordinates (defining points), and radius or arc flags, the sequence describing a complex geometric shape from successive drawing portions (each corresponding to a command), like lines, Bezier curves and/or arcs.
The path defining the shape outline is written in the attribute “d” of the XML element, and can be written using either absolute coordinates or relative coordinates. Relative coordinates are written on the basis of the preceding coordinates in the path.
The draw commands are defined by letters, where uppercase letters specify the use of absolute coordinates while lowercase letters correspond to relative coordinates. By using both uppercase and lowercase letters, absolute and relative coordinates can be mixed within the same path.
As an example, the two following paths represent the same complex geometric shaped, the first one containing absolute coordinates while the second is made of relative coordinates.                M14.0, 70.9 L14.0, 55.0 L 2.0, 71.0 L14.0, 70.9 Z        m14.0, 70.9 1 0.0,−15.9 l−12, 16.0 l12.0, −0.1 z        
“M” or “m” is a “move-to” draw command defining a new geometric point to consider.
“L” or “I” is a line command specifying the end point of the line.
“Z” is a closepath command, closing the outline of the path by a straight line between the last processed point and the first point of the path.
A “C” or “c” command defines a cubic curve. The latter requires six parameter values as shown in FIG. 1: (x1,y1) is the first control point, (x2,y2) is the second control point and (x,y) is the destination point of the curve, the initial point of the curve being the destination point (xe, ye) of the previous command.
SVG curve commands also comprise an “S/s” smooth cubic curve command, a “Q/q” or “T/t” Quadratic Bézier command or an “A/a” Elliptical arc command.
The present invention relates to the encoding of XML-based documents of SVG type.
Since XML has a verbose syntax to describe the structure of a document, specific encoding mechanisms for XML have been investigated to encode the content of an XML document in a more efficient format while maintaining the ability to easily rebuild the original XML document.
Binary XML formats have thus been developed, including the Fast Infoset format and the Efficient XML Interchange (EXI) format.
Those two formats use index tables to encode the new occurrences of repeated content or structural elements with an associated index, instead of the whole content or structural element. Bits for encoding the XML document are then saved. The majority of the saving is generally due to structural information.
While Binary XML formats can be used to encode SVG documents, most of these formats are not adapted to such encoding in a compact way.
This is because SVG documents comprise a small part of structural information compared to the content part.
This is also because large SVG contents are rarely repeated and are usually of a complex type for which the efficiency of the known Binary XML encoding dedicated to simple data type, such as integer or float, cannot be taken advantage of. Those large contents are for example graphics paths, which mix simple graphics commands with coordinates, or a list of values (both integer and float).
Several specific Binary XML encoding formats for SVG documents have therefore been developed.
In particular, from U.S. Pat. No. 6,624,769, a method is known that separately encodes the draw commands and the associated integer arguments of an SVG path sequence.
Firstly, the commands are encoded by attributing a Huffman-like code only to commands used in the graphics path, therefore reducing the number of codes (i.e. bits) used.
Secondly, the arguments, which are only integers since the SVG profile of the patent is dedicated to mobile phones, are encoded in a binary format using the minimum number of bits allowing encoding any argument contained in the graphics path. The arguments are split into two categories: arguments belonging to absolute uppercase letter commands and arguments belonging to relative lowercase commands.
For each category of arguments, the minimum number of bits allowing encoding all the arguments of this category is calculated. Then, each argument is encoded using a number of bits depending on its category.
By adjusting the number of bits to the minimum required to encode a category of arguments or the commands, this format provides an efficient compression of SVG documents.
There is also known, from US patent application publication No. 2008/0063114, a lightweight application scene representation (LASeR) binary XML format targeted to encoding SVG documents.
According to this application, the encoding of an SVG path sequence uses the better of two methods to encode arguments.
The first method plans to encode the first two arguments using a first bit-length, and to encode all remaining arguments as relative arguments using two other bit-lengths. The first bit-length is the minimum bit-length allowing encoding the first two arguments. The two other bit-lengths are computed in a similar way: the first other bit-length is the minimum bit-length allowing encoding of all relative abscissa coordinates, while the second other bit-length is the minimum bit-length allowing encoding all relative ordinate coordinates.
The second method plans to encode the first two arguments using a first bit-length, and to encode all further arguments as relative arguments using an exponential-Golomb encoding.
However, the solutions disclosed in these two publications suffer from several drawbacks.
In particular, the rendering of the encoded SVG drawing requires the decoding of all the information of the SVG path to draw and display a complete image.
For rendering an SVG image into thumbnails or small rendering sizes, the data path precision is generally too great such that the processing of the encoded SVG data wastes time.
Therefore, there is a need to provide a method for encoding a graphics document, such as an SVG document, which can be dedicated to partial decoding and/or progressive rendering, while retaining good compression performance.
Another specific Binary XML format dedicated to the SVG documents is disclosed in a presentation from Expway (www.mitre.org/news/events/xml4bin/pdf/thienot_binary.pdf, slides 53-56).
The disclosed method conducts a linear quantization of the coordinate values to encode the latter over a smaller number of bits, for example 7 to 9 bits. As shown by the exemplary figures of this presentation, the method drastically reduces the precision of the path data and the rendered drawing.
This method also suffers from several drawbacks.
The Expway method is a lossy compression that does not allow recovery of the full resolution of the original image.
It is desirable to have a graphics path encoding enabling partial decoding or progressive rendering.